出处：掘金

原作者：ErpanOmer

有一天下午四点，我点开了同事刚提的一个 PR，先上代码：

async function handle(list) {
  const list1 = []
  let temp = null
  const a = 1

  for (let i = 0; i < list.length; i++) {
    if (list[i]) {
      if (list[i].status) {
        if (list[i].status === 'active') {
          if (list[i].type) {
            if (list[i].type === 'user') {
              // 在 for 里 await 查库
              temp = await db.query(
                'SELECT * FROM users WHERE id = ?',
                [list[i].id]
              )

              if (temp && temp.length > 0) {
                list1.push(temp[0])
              }
            } else {
              if (a === 1) {
                // 什么都不干
              }
            }
          }
        }
      }
    }
  }

  return list1
}

• 第一眼，还行。
• 第二眼，嗯？
• 第三眼，我开始怀疑人生。

变量叫 a、temp、list1，if-else 套了六层，在 for 里 await 查库，像一锅没加盖的乱炖

我当时脑子里只有一个念头：这玩意要是上线了，今晚谁都别睡😡😡😡

但问题是 —— 你不能在评论区直接敲一句：

这段代码太烂了，建议重写

你可以这么想，但不能这么说。因为你不是在写技术博客，你是在上班

Code Review 本来是为了让项目更稳，结果很多时候，反而成了团队关系的坟头

后来我慢慢意识到一件事：你要做的，不是指出问题，而是让对方愿意帮你把问题改掉

先说个核心原则：别对人下手，先对代码下手

CR 最容易翻车的点，就一个字：你

你这里写错了、你为什么不判空、你这逻辑不太行

只要你用了“你”，对方心里的防御盾基本就举起来了

更聪明的做法，是把对象换掉

• 换成我们
• 换成这段代码
• 换成如果这个场景
• 换成我们下次如何防范

比如：

我们这里可能要考虑一下空变量的情况。这段逻辑在并发高的时候，可能会有点风险，这个写法在数据量大的时候，性能可能撑不住的

意思一点没变，但攻击性直接砍半。 敌人是 Bug，不是你的同事

一些能救命的 CR 话术

变量名随便起，看不懂

你心里想的是：

这 list1 到底是个啥？

但你可以这么说：

这个 list1 里装的主要是什么数据来着？

要不要换个更具体点的名字，比如 activeUserList？

这样后面维护的人（包括未来的我们）会省不少事

重点不在你命名不行，而是以后接受的人会感谢你的

if-else 套到你头皮发麻

别说逻辑太乱了

你可以说：

这里我看了一下，逻辑稍微有点绕，我读了两遍才理顺

要不要考虑用提前 return 的方式拆一下？

缩进少一点，后面看起来也轻松些

先承认是我读得有点费劲，再给建议，最后用商量的语气收尾

对方台阶都有了，基本不会炸

明显的性能隐患

比如循环里查库、循环里调接口

可以这样：

这个写法在当前数据量下应该没啥问题

我主要有点担心，如果后面数据上来，接口时间会不会被拉长

要不这里改成批量查或者并发一下？稳一点

这句话的潜台词只有一个：我是在给项目兜底

完全看不懂他在干嘛？

这时候千万别装懂

你可以说：

这块我好像没太跟上你的思路，

能不能简单说下这里为什么要这么处理？

或者加点注释也行，我怕下次有人接手会有点懵

很多时候，对方在解释的过程中，自己就会发现问题

你甚至都不用再补刀的

顺便说一句：别做格式检查

CR 不是让你盯着：

• 少没少空格
• 单引号还是双引号
• 换行对不对
• 有没有写注释
• 有没有加 commit 标签

你在 PR 里留 20 条这种评论，对方只会想一件事：这人是不是有点烦

格式这种事，交给工具就完了：ESLint、Prettier、Husky，甚至是 AI 整理代码能解决 80% 的低级争吵

如果真的乱到影响阅读，可以一句话带过：

这一块缩进好像有点乱，

跑一下 lint 自动修一下就行，

我们主要还是看下逻辑

点到为止

真到必须重写的时候，别在评论区硬刚

有些代码，确实已经到了不改不行的程度。但就算这样，也别在 PR 评论区写小作文

人多的地方，没人愿意认输

更好的方式是：

私聊？语音？当面？

开场也别太重：

刚看了下那个 PR，有一块我有点担心，咱们对一下怎么样？

把风险讲清楚， 把后果讲明白，共识达成了，再让他自己改

给成年人留面子，成本真的很低的

说个实在的

Code Review 从来都不是，谁技术更牛谁说了算的。你今天指出的问题， 很可能是为了防止哪天半夜两点， 把他从被窝里拽起来修 Bug

这不是找茬，这是在剩你的时间

所以以后 CR 的时候：

• 少一点命令
• 多一点商量
• 少一点“你怎么这样？”
• 多一点“我们是不是可以？”

代码是冷的，但一起写代码的人，最好别凉